Proposal for improving pure situation, #3755
Conversation
…valid and that users can update. Closes modelica#3719 Note that in addition to the changes in the issue reordered the items and changed "must" to "should" for the deprecated semantic, and clearly indicated that the exception is the deprecated case. (Having a "must"-requirement and then have exceptions for it just seems wrong.)
| External functions should be explicitly declared with \lstinline!pure! or \lstinline!impure!. | ||
| The case without the keyword is deprecated semantics described in the next item. |
There was a problem hiding this comment.
I saw your comment, but I don't agree that this is the style in which the specification is written. I believe this is how we do it:
| External functions should be explicitly declared with \lstinline!pure! or \lstinline!impure!. | |
| The case without the keyword is deprecated semantics described in the next item. | |
| External functions shall be explicitly declared with \lstinline!pure! or \lstinline!impure!. | |
| A deprecated semantics is that an external function declared with neither \lstinline!pure! nor \lstinline!impure! is handled according to the next item. |
There was a problem hiding this comment.
The usual specification define of shall/should is rfc2119 - and deprecated mean discouraged, not forbidden.
Combined I don't see that one can combine "shall" and deprecated in that way.
Modelica Specification could be different, but I could not find any such uses of deprecated combined with shall/should/must/may but instead found:
- builtin (deprecated) https://specification.modelica.org/master/functions.html#external-function-interface - included among allowed ones
- https://specification.modelica.org/master/operators-and-expressions.html#modelica:cardinality - deprecated, should not be used
- https://specification.modelica.org/master/inheritance-modification-and-redeclaration.html#restrictions-on-the-kind-of-base-class A class may only contain class definitions, annotations, and extends-clauses (having any other contents is deprecated).
- Although all pointer types are const pointers in the type mapping for input arguments, it is
a deprecated feature that the prototype in an Include annotation may use non-const pointers
instead. - https://specification.modelica.org/master/packages.html#file-system-mapping-of-package-class A deprecated feature is that the file may start with the UTF-8 encoded BOM
- https://specification.modelica.org/master/packages.html#external-resources As a deprecated feature the URI may start with modelica:// and use the host-part of the authority as the
fully qualified package name. That feature is widely used, but deprecated since host-names are generally
case-insensitive
There was a problem hiding this comment.
The way I read the proposal, a tool should generate a deprecation warning for every function not explicitly declared pure or impure. This makes it hard to make sense of the "normally" rule in the beginning.
Am I getting the intention right if I think the goal is to:
- Lack of explicit purity of an external function is deprecated.
- For a function not declared
impure, it is deprecated to call an external function not declaredpure. (Hence, making theimpureof an external function explicit will address one deprecation warning without leading to new ones.) - For a function without explicit purity, it is deprecated to call any function declared
impure. (Making theimpureof an external function explicit will cause an error if called from a function explicitly declaredpure.) - A function is assumed impure in the following cases (applied recursively):
- It is declared
impure - It is an external function without explicit purity
- It calls another function assumed impure
- It is declared
- (A function not assumed impure is assumed pure.)
What I am trying to capture above is that the deprecation rules have only to do with the explicit declaration of functions as pure or impure, whereas the reasoning about impure behavior is based on rules which are formulated so that they make sense regardless of deprecated (lack of) purity declaration.
Co-authored-by: Henrik Tidefelt <[email protected]>
That wasn't the intention, the new semantics was only intended to kick in if:
That is a bad combination, and shouldn't be common. The proposed semantics ensure that MSL 4.1.0 is kind of valid. And even more importantly, it also avoids breaking user libraries/models in the same way that rely on those functions in MSL. |
2 participants
To ensure that current MSL is valid and that users can update.
Closes #3719
Note that in addition to the changes in the issue reordered the items and changed "must" to "should" for the deprecated semantic, and clearly indicated that the exception is the deprecated case.
(Having a "must"-requirement and then have exceptions for it just seems wrong.)